Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/networking/cisco/fastigrp.doc

Internet Message Format | 1992-08-07 | 3.8 KB

From: [e-mail]
Message-Id: <[e-mail]>
To: [e-mail]
Subject: fast IGRP

I thought people might be interested in knowing our experience using
what I call "fast IGRP", i.e. a set of options available under 8.1
that greatly speeds up IGRP's adoption of new routes when something
changes.

There are two options that you want to use in order to speed up IGRP's
adjustment: "timers basic" and "no metric holddown".  "Timers basic"
lets you control how often IGRP sends updates.  The default is once
every 90 sec.  In order to allow for dropped packets, IGRP can't time
out expired routes until several minutes have elapsed.  When it
removes a route, it can't adopt a new one for several more minutes due
to holddown.  So using default parameters, it can take up to 9
minutes to adapt to a change.

The first thing we do is to speed up the time constants.  We use 15
sec instead of 90 for the basic time constant.  This allows us to
expire routes after 45 sec.  We decrease all the other times
proportionally.

Actually, the expiration time turns out not to be as important as you
might expect.  Normally routes don't just expire.  They are killed
because keepalive fails on some interface, or you lose carrier.
Keepalives are normally done every 10 sec, so it takes 30 sec to
detect an interface down that way.  We use keepalive of 4 on T1 lines
where we care about speed of routing adjustment.  This lets us detect
a failure in 12 sec.

The other critical parameter change is "no metric holddown".  This
disables holddowns, meaning that after a route has been removed, a new
one will be accepted immediately.  There were good theoretical reasons
for using holddowns.  One can come up with pathological cases where
without holddowns, an old route will never get out of the system.
However 8.1 has a couple of checks to prevent bad routes from
surviving indefinitely.  We have not seen any old routes staying
around.  Note that 8.1 does keep a hop count, specifically to get rid
of old routes that somehow manage to avoid the other tests.  If you do
"show ip protocol", you'll notice an "IGRP maximum hopcount" of 100.
If all else fails, IGRP will go into "count to infinity", and stop at
100.  Since IGRP uses triggered updates, counting to 100 may not take
too long.  However I recommend setting maximum hopcount to something
smaller (unless you have an enormous network).  It should be a number
at least as large as the "diameter" of your network, i.e. the maximum
number of routers a route might ever have to go through.  If you
exchange IGRP routing with an external network, the diameter must
include your network plus that external network.  When you compute
diameter, take into account what the configuration would look like
if a few lines go down.

Here's an example router statement that uses all of these features.
Obviously you'd put your own network number in place of 128.6.0.0.

   router igrp 46
   timers basic 15 45 0 60
   network 128.6.0.0
   no metric holddown
   metric maximum-hop 50

With this, routing will generally adapt to change within 30 sec,
assuming that keepalive has been set down to 4.

The obvious concern about turning up IGRP is that you'll use up your
whole box running routing.  Our network has 75 subnets.  There's a
fairly good amount of redundancy in it.  On a CSC2, IGRP with these
settings takes 1-3% of the CPU for our major gateways (with 4-6
interfaces), and .2% in one gateway that's in a "backwater".  (These
numbers come from looking at the CPU time used, as reported by "show
process", and dividing by the amount of time the box has been up, as
reported by "show harware".)  You'd expect the time to be proportional
to the number of subnets and to the frequency of running IGRP.  I
don't think we'd want to run IGRP quite this fast if we were
circulating the whole Internet routing table.